System and apparatus for transaction data format and function verification

ABSTRACT

A system for processing transaction data is provided. The system includes a transaction data format system receiving transaction data and generating transaction data format error data, such as when the transaction data is not in compliance with a transaction data format. The system also includes a transaction data rules system receiving the transaction data and generating transaction rule error data, such as when the transaction data is in the proper format but nevertheless violates a rule of one or more financial processing system.

FIELD OF THE INVENTION

The present invention pertains to the field or transaction dataprocessing. More specifically, the invention relates to a system andapparatus for transaction data processing that specifies data formatsrelated to functions performed for different financial processingentities.

BACKGROUND

Transaction processing systems are known in the art. Such transactionprocessing systems receive transaction data from merchants and assemblethe data for transmission to financial processing systems, such as banksor credit card issuing organizations. These transaction processingsystems receive data from the merchant in the format dictated by thefinancial processing system, and forward the transaction data on forsubsequent processing in large files known as “batch files.” These batchfiles are usually submitted once every day, or at other periodic times.

While such transaction processing systems perform certain usefulfunctions, the merchant must ensure that the data that has been enteredis in the proper format and falls within allowable boundaries for eachfinancial processing system. Each financial processing system hasspecialized data formats and functions, which further complicates theprocessing of transaction data. When a merchant has failed to providedata in the proper format or within allowable boundaries, the financialprocessing system generates an error message that is then transmitted ina batch file to the merchant through the transaction processing system.Thus, the process of correcting the data can take several days, whichcan be further complicated if personnel are entering incorrect datafields and are unaware of that condition until the error messages arereceived and processed.

SUMMARY OF THE INVENTION

In accordance with the present invention, a system and apparatus forprocessing transaction data are provided that overcome known problemswith processing transaction data.

In particular, a system and apparatus for processing transaction dataare provided that check the transaction data to determine whether it isin a proper format for one of two or more financial processing systems,and that further check the transaction data to ensure that it complieswith one or more rules of two or more financial processing systems.

In accordance with an exemplary embodiment of the present invention, asystem for processing transaction data for two or more financialprocessing systems is provided. The system includes a transaction dataformat system receiving transaction data and generating transaction dataformat error data, such as when the transaction data is not incompliance with the transaction data format for the selected financialprocessing system. The system also includes a transaction data rulessystem receiving the transaction data and generating transaction ruleerror data, such as when the transaction data is in the proper formatbut nevertheless violates a rule of one or more financial processingsystem.

The present invention provides many important technical advantages. Oneimportant technical advantage of the present invention is a system andapparatus for processing transaction data that determines whether aformat error or rules error has been committed by a merchant that hassubmitted the transaction data for two or more financial processingsystems. The present invention thus ensures that the data provided toeach financial processing system not only is in the proper format, butalso meets any functional requirements.

Those skilled in the art will further appreciate the advantages andsuperior features of the invention together with other important aspectsthereof on reading the detailed description that follows in conjunctionwith the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a system for processing transaction data inaccordance with an exemplary embodiment of the present invention;

FIG. 2 is a diagram of a system for providing transaction rulesprocessing in accordance with an exemplary embodiment of the presentinvention;

FIG. 3 is a diagram of a system for providing processing status rulefunctionality in accordance with an exemplary embodiment of the presentinvention;

FIG. 4 is a flow chart of a method for performing transaction processingin accordance with an exemplary embodiment of the present invention; and

FIG. 5 is a flow chart of a method for performing transaction ruleviolation processing in accordance with an exemplary embodiment of thepresent invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the description which follows, like parts are marked throughout thespecification and drawings with the same reference numerals,respectively. The drawing figures may not be to scale and certaincomponents can be shown in generalized or schematic form and identifiedby commercial designations in the interest of clarity and conciseness.

FIG. 1 is a diagram of a system 100 for processing transaction data inaccordance with an exemplary embodiment of the present invention. System100 allows transactions such as credit card transactions, debit cardtransactions, or other suitable transactions to be processed through acentralized system, such that merchants can readily interface with anumber of different financial processing systems.

System 100 includes transaction processing system 102 and merchantinterface system 104, which can be implemented in hardware, software, ora suitable combination of hardware and software, and which can be one ormore hardware systems, or one or more software systems operating on ageneral purpose processing platform. As used herein, a hardware systemcan include discrete semiconductor devices, an application-specificintegrated circuit, a field programmable gate array or other suitabledevices. A software system can include one or more objects, agents,threads, lines of code, subroutines, separate software applications,user-readable (source) code, machine-readable (object) code, two or morelines of code in two or more corresponding software applications,databases, or other suitable software architectures. In one exemplaryembodiment, a software system can include one or more lines of code in ageneral purpose software application, such as an operating system, andone or more lines of software in a specific purpose softwareapplication.

Transaction processing system 102 is coupled to merchant interfacesystem 104 and financial processing systems 106A through 106N overcommunications medium 116. As used herein, the term “couple” and itscognate terms, such as “couples” and “coupled,” can include a physicalconnection (such as a copper conductor), a virtual connection (such asthrough randomly assigned memory locations of a data memory device), alogical connection (such as through logical gates of a semiconductingdevice), other suitable connections, or a suitable combination of suchconnections. In one exemplary embodiment, systems and components arecoupled to other systems and components through intervening systems andcomponents, such as through an operating system. Communications medium116 can be a local area network, a wide area network, a public networksuch as the Internet, the public switched telephone network, a wirelessnetwork, a fiber optic network, other suitable media, or a suitablecombination of such media.

Transaction processing system 102 receives transaction data frommerchant interface system 104 and provides the transaction data to theproper financial processing system 106A through 106N. In addition,transaction processing system 102 determines whether the data formatrequirements of the associated financial processing system 106A through106N have been satisfied. Transaction processing system 102 alsoperforms a rules check on the transaction data, such as to determinewhether the rules of the proper financial processing system 106A through106N have been complied with.

In general, when a merchant submits transaction data for processing by afinancial processing system, the merchant must comply with the financialprocessing system's data format requirements and rules. For example, thefinancial processing system may have a data format that must be followedby each merchant. Likewise, each financial processing system will haverules regarding how transaction data can be submitted, what must be donein circumstances to respond to a request for authorization or settlementprocess, and other suitable rules. For example, the rules for processinga credit card transaction are different from the rules for processing adebit card transaction. Transaction processing system 102 can utilize astandardized format, such as an extensible mark-up language (XML) datatype definition (DTD) that allows the data received from merchantinterface system 104 to be standardized, and which further allowstransaction processing system 102 to map the data to the appropriatefinancial processing system 106A through 106N data format. In thismanner, transaction processing system 102 eliminates the need foroperators of merchant interface system 104 to gather and format data indifferent formats based on the financial processing system 106A through106N that the transaction data is being transmitted to. Likewise,transaction processing system 102 can verify that the rules of theassociated financial processing system 106A through 106N have beencomplied with, and can immediately request the merchant or operator ofmerchant interface system 104 to correct any problems with a data formaterror or a transaction rule error, rather than requiring such errors tobe identified only after processing by the financial processing system106A through 106N, which can cause delay and add expense to theprocessing of the transaction.

Transaction processing system 102 includes transaction data formatsystem 108 and transaction rules system 110, each of which can beimplemented in hardware, software, or a suitable combination of hardwareand software, and which can be one or more software systems operating ona general purpose processing platform. Transaction data format system108 provides transaction data format data to merchant interface system104, and determines whether the data provided in response complies withthe applicable transaction data format. In one exemplary embodiment,transaction data format system 108 can include an XML DTD or othersuitable data definitions that can be used by an operator of merchantinterface system 104 to design an interface for transaction processingsystem 102. A suitable group of two or more of the fields can beidentified as mandatory fields, so as to prevent the data from beingused by unauthorized parties, to perform fraud monitoring, to performquality control, or for other suitable purposes. An exemplary embodimentof such as XML DTD is shown in TABLE 1 below:

TABLE 1 MAX. LABEL LENGTH DESCRIPTION AC N/A Required XML Parent Tag.AccountNum 19  Card Number identifying the customer. AccountTypeInd 2Defines Account type. AdjustedAmt 12  Amount for Partial Voids ifnecessary. Amount 12  Transaction Amount. AmountDetails N/A XML ParentTag for defining the Transaction amount details. AttendedTermDataInd 2Indicates if the card acceptor was at the point of sale. Auth N/A XMLParent Tag. AuthCharInd 1 Code issued by Card Issuer for CPS evaluationAuthCd 6 Prior Authorization Code. AuthCode 6 Issuer approval Codedelivered in response. AuthID 6 Populated for incremental and reversalauthorizations. AuthMandatory N/A Required XML Parent Tag. AuthNetwkld 2Code indicating network that processed the transaction. AuthOptional N/ARequired XML Parent Tag. AuthSrc 1 Code indicating how authorization wasperformed. AVSaddress1 30  Cardholder Billing Address line 1.AVSaddress2 30  Cardholder Billing Address Line 2. AVSbase N/AIdentifies that Address Verification (AVS) data will be submitted for aRecurring Transaction. AVScity 20  Cardholder Billing City. AVSextendedN/A XML Parent Tag for eCommerce address verification request. AVSname30  Cardholder/Checkholder Billing Name. AVSRespCd 2 Addressverification request response. AVSstate 2 Cardholder Billing State.AVSzip 10  Cardholder Billing Address Zip Code. BankAccountType 1Defines the deposit account type. BankCheck N/A Electronic Check (ECP)XML Parent Tag for all associated elements and attributes of the cardtype. BankNetDate 4 Generated response date. BankNetRefNo 9 Generatedidentifier for each original auth request. BankPmtDelv 1 Defines the ECPdelivery method. Batch N/A XML tag that defines the transaction as abatch [EOD] request. BatchResponse N/A XML tag that defines thetransaction as a batch [EOD] response. BCR†Num 9 Bank routing andtransit number for the customer. For Electronic Check processing. BIN 6Transaction Routing Definition. Cap N/A Required XML Parent Tag.CapMandatory N/A Required XML Parent Tag. CapOptional N/A Required XMLParent Tag. CaptureStatus 1 Status of Capture Request. CardBrand 2Defines the Card Type/Brand for the Transaction. CardholderAttendanceInd2 Indicates if the cardholder was present at the POS. CardlssueNo 2European Debit Card. CardNP N/A XML Parent Tag which defines thetransaction as Card not present and the associated data elements thatcan be submitted as a result. CardPresence N/A XML Parent Tag in whichchild elements are card present or card not present. CardPresentInd 1Indicates if the card was present at the POS. CardSecVal 4 CVV2 number.CardStartDate 4 European Debit Card (Switch Record Format Only).CardType N/A XML Parent tag which defines the Card Type and Brand.CATInfoInd 2 Indicates type of Cardholder Activated Terminal (CAT).CheckDDA 17  Customer DDA account number for Electronic Checkprocessing. Comments 64  Free form comments. CommonData N/A Required XMLParent Tag. CommonMandatory N/A Required XML Parent Tag.CommonMandatoryResponse N/A XML tag sent in an authorizations,Auth-Captures, and Mark for Capture response. CommonOptional N/A XMLParent Tag. Currency N/A XML Parent Tag which can include Currency dataattributes. CurrencyCode 3 Defines the transaction currency.CurrencyExponent 6 Defines the transactions currency exponent.CVV2RespCd 1 Card verification value request response. DebitCard N/ASwitch - Solo XML Parent Tag for all associated elements and attributesof the card type. DebitCardIssueNum 2 Switcn - Solo incremental counterfor Lost or replacement cards. DebitCardStartDate 4 Switch - Solo cardsactivation date. DownGradeReason 2 Interchange Downgrade Reason Code.EcommerceData N/A XML Parent Tag that defines the transaction as asingle purchase eCommerce transaction and the required data elements andattributes of that transaction type. ECOrderNum 16  Merchant DefinedOrder Number. ECSecurityInd 2 Defines Electronic Commerce security.EntryDataSrc 2 Indicates how primary Account number originally entered.ErrBitNo 3 Internal message mapping error location for this transaction.ErrSubtagVal 2 Internal message mapping error location for thistransaction. Exp 4 Card Expiration Date. FormatInd 1 Determines formatof additional data submitted in the subsequent XML Tag <AuthOptional>hierarchy, such as Home AVS with Telephone format data included, WorkAVS with Telephone format data included, Electronic Check format dataincluded, European debit Card Switch (Switch Card format data included).HcsTcsInd 1 Constant ‘T’. HostAVSRespCd 2 Actual host addressverification response code. HostCVV2RespCd 1 Actual host addressverification response code. HostRespCd 3 Actual host response code.LangInd 2 Language Indicator. MailOrderData N/A XML Parent Tag thatdefines the transaction as a recurring purchase and the required dataelements and attributes of that transaction type. MailOrderNum 9Merchant Defined Order Number. MailOrderTypeInd 1 Mail order indicatorto describe the type of transaction. MCInterchangeInd 1 InterchangeCompliance Data. MCPurchCardInd 1 Business Card Type Indicator.MerchantID 15  Gateway merchant account number. MerchantSIC 4 Merchant'sStandard Industry Code (a.k.a MCC). MessageType 4 Defines Message Type,such as authorization request, authorization and mark for capture,capture, void, refund, and batch release. OrderID 16  Merchant DefinedOrder Number. OrigAuthAmt 12  Identifies the original amount authorizedin Mark for Capture responses. OutstandingAmt 12  Remaining Non-voidedamount for partial Voids. PCCore N/A XML Parent Tag for 2 of 4Purchasing Card II Data Elements. POSCardID 1 Defines cardholderlocation. POSConditionCode 2 Code that defines the POS environment.POSEntryMode 2 Code that defines the method to process cardholderaccount. POSValidCode 1 MC POS Entry Mode Validation Response.PriorAuthID N/A Defines the transaction type as a Prior Auth. ProcStatus6 Process Status. PCDestZip 10  Shipping Destination Zip code for thepurchase. PCOrderNum 17  PO number or Order number from customer.QuickResponse N/A XML tag that defines the transaction as an QuickResponse which is an error condition. Refund N/A XML tag that definesthe transaction as a Refund request. RefundResponse N/A XML tag thatdefines the response as a Refund Response. Request N/A XML Parent Tag.RespCode 2 Response Code. RespDate 6 The date a response was generatedby the Gateway. RespMessage 80  Messages associated with RespCode.RespTime 14  Date/time transaction was processed by gateway.ResponseCodes N/A XML tag in which all host response elements aredelivered. ShippingRef 40  Shipping Tracking Reference Number. StatusMsgVar Text message associated with ProcStatus value. StatusMsgLth 4 Lengthof StatusMessage. Tax 12  Tax Amount for the purchase. TaxInd 1 Definesthe tax amount TermEntCapInd 2 Code that defines the method to processcardholder account. TerminalID 3 Merchant Terminal ID. TermLocInd 2Indicates terminal location. TotAuthAmt 12  This is the net amount forall authorizations for this transaction. TransErrNo 5 Internal errornumber for this transaction. TransID 15  Identifier for each originalauth request. TxCatg 1 Defines transaction type. TxRefldx 4 Gatewaytransaction index. TxRefNum 40  Gateway transaction reference number.TzCode 3 Time zone for Merchant. TxDateTime 14  Transaction date andTime. TxTypeCommon N/A Required XML Parent Tag for TxTypeId andPriorAuthID TxTypeID 2 Defines the transaction type: G—Goods & servicesValidationCd 4 Validation code supplied for CPS qualification Version 1Constant ‘2’ VisaCommCard 1 Indicates commercial card. Void N/A XML tagthat defines the transaction as a Void request. VoidResponse N/A XML tagthat defines the transaction as a Void response.

Likewise, the merchant interface system 104 can be implemented using aweb browser, such that transaction processing system 102 transmits therequired transaction processing forms for web transactions, card notpresent transactions, interfacing with a point of sale device, or othersuitable forms.

Transaction rules system 110 implements transaction processing rulesimposed by card organizations, financial processing systems, transactionprocessing system 102, or other suitable rules. In one exemplaryembodiment, the data entered in response to a form specified bytransaction data format system 108 may meet all formal requirements, butmay be outside of boundaries allowed under a transaction rules system.Transaction rules system 110 tests the data entered to determine whetherit complies with the transaction rules.

Merchant interface system 104 includes error display system 112 andcorrective action system 114, each of which can be implemented inhardware, software, or a suitable combination of hardware and software,and which can be one or more software systems operating on a generalpurpose processing platform. Error display system 112 receives errordata from transaction processing system 102 and generates an errormessage or notification. In one exemplary embodiment, error displaysystem 112 can be XML data, HTML data, or other suitable datatransmitted by transaction processing system 102 that generates a screenon a web browsing system of merchant interface system 104, or othersuitable processes can be used. Error display system 112 notifies theuser of the transaction data format or transaction rule that has beenviolated, identifies the data that violated the transaction data formator transaction rule, and performs other suitable functions.

Corrective action system 114 receives correction data from a user andprovides the correction data to transaction processing system 102 inresponse to a transaction data format error or a transaction rule error.In one exemplary embodiment, corrective action system 114 includes anerror explanation field that provides explanatory data for the user thatdescribes the data should be entered, the problem with the data that wasentered, or other suitable data, a data entry field that allows the userto replace only the defective entry field, and can further allow a userto replace additional data entry fields where suitable if such dataentry fields are related to the error field.

In operation, a user of merchant interface system 104 providestransaction data to transaction processing system 102. The transactiondata can be provided by interfacing with a web server that receives datafrom other users and which combines such other user data with data frommerchant interface system 104, such as transaction identifier data,customer identifier data, merchandise data, or other suitable data. Thetransaction data is then transmitted to transaction processing system102, where it is determined whether all the transaction data is in aproper transaction data format through transaction data format system108, and where it is further determined whether transaction rules havebeen followed for the respective financial processing system. If it isdetermined that a transaction data format error has been included in thetransaction data, transaction processing system 102 and transaction dataformat system 108 transmit error data to merchant interface system 104and error display system 112, including but not limited to anidentification of the data field that is in error, what the data fieldstands for, what the error relates to, or other suitable data. Likewise,transaction processing system 102 and transaction data format system 108can provide data to corrective action system 114 to prompt the user toreplace the defective data with corrected data. Likewise, merchantinterface system 104 can include error display system 112 and correctiveaction system 114, such that transaction codes only are sent bytransaction data format system 108 and transaction rules system 110.

After the transaction data format, has been verified, transaction rulessystem 110 determines whether the data values entered are withinallowable data ranges. Likewise, transaction rules system 110 determineswhether the data values entered relate to other data values in anallowable manner. For example, providing a charge for a transaction on adate that occurs in the future might not be permitted under financialprocessing system rules. Likewise, other suitable rules can beimplemented by transaction rules system 110. If a transaction rule errorhas occurred, error display system 112 can notify the user of thetransaction rule error, and corrective action system 114 can request theuser to enter corrected data. After the transaction data format andtransaction rules have been satisfied, transaction processing system 102transmits the transaction data to the appropriate financial processingsystem 106A through 106N, such as by first mapping the data into anappropriate financial processing system data format. Transactionprocessing system 102 also receives response data from the financialprocessing systems 106A through 106N, and can further map the responsedata from the financial processing system data format to an appropriateformat, and can transmit that data to merchant interface system 104 foradditional processing, corrective actions, or other suitable processes.

FIG. 2 is a diagram of a system 200 for providing transaction rulesprocessing in accordance with an exemplary embodiment of the presentinvention. System 200 includes transaction rules system 110 andauthorization response rules system 202, address verification rulessystem 204, card verification value rules system 206, processing statusrules system 208, and downgrade rules system 210, each of which can beimplemented in hardware, software, or a suitable combination of hardwareand software, in which can be one or more software systems operating ona general purpose processing platform.

Authorization response rules system 202 receives transaction data andgenerates authorization response rules error data. In one exemplaryembodiment, the authorization response rules system 202 can determinewhether a transaction has been authorized, whether fraud indicatorsexist, whether an account number or PIN number is invalid, or othersuitable functions. For example, the exemplary authorization responserules shown in TABLE 2 and TABLE 3 can be implemented by authorizationresponse rules system 202:

TABLE 2 ACTION DESCRIPTION Call Call Customer Service for assistance.Cust. Try to resolve with customer or obtain alternate payment method.Fix There is an invalid value being sent. Fix and resend. Send Send thistransaction back at any time. Voice Perform a voice authorization perinstructions. Wait Wait 2-3 days before resending or try to resolve withcustomer.

TABLE 3 CODE RULE STATUS ACTION  0 Approved Approved None  1 Call/Referto Card Issuer Decline Voice  2 Refer to Card issuer's special DeclineVoice conditions  3 Invalid Merchant Number Error Fix  4 Pickup DeclineCust.  5 Do Not Honor Decline Cust.  6 Other Error Decline Cust.  8Approved authorization, honor with Approved None identification 10Default Call Decline Voice 11 Approved authorization, VIP Approved NoneApproval 12 Invalid Transaction Type Decline Cust. 13 Bad Amount DeclineFix 14 Invalid Credit Card Number Decline Fix 15 Default Call Low FraudDecline Voice 16 Default Call Medium Fraud Decline Voice 17 Default CallHigh Fraud Decline Voice 18 Default Call Unavailable Fraud Decline Voice19 Re-enter Transaction Error Resend 20 Floor Low Fraud Decline Cust. 21Floor Medium Fraud Decline Cust. 22 Floor High Fraud Decline Cust. 23Floor Unavailable Fraud Decline Cust. 24 Validated Approved None 25Verified Approved None 26 Prenoted Approved None 27 No reason to declineDecline Cust. 28 Received and stored Approved None 29 Provided AuthApproved None 30 Invalid value in message Error Fix 31 Request receivedApproved None 32 BIN Alert Approved None 33 Card is expired DeclineCust. 34 Approved for partial Approved None 35 Zero Amount Error Fix 36Bad Total Auth amount Error Fix 40 Requested Function not supportedError Call or Fix 41 Lost/Stolen Decline Cust. 43 Lost/Stolen CardDecline Cust. 50 Positive ID Decline Cust. 52 Processor Decline DeclineCust. 56 Restraint Decline Cust. 58 Transaction not permitted to ErrorCall terminal 59 Soft AVS Decline Cust. 60 Do Not Honor Low FraudDecline Cust. 61 Do Not Honor Medium Fraud Decline Cust. 62 Do Not HonorHigh Fraud Decline Cust. 63 Do Not Honor Unavailable Fraud Decline Cust.64 CVV2/CVC2 Failure Decline Cust. 65 Invalid CID Decline Cust. 66 OtherError Error Fix 68 Invalid CC Number Error Fix 69 Does not match MOPError Fix 71 No Account Decline Fix 72 Invalid Institution Code DeclineFix 73 Method of Payment is Invalid for Error Fix Merchant 74 InvalidExpiration Date Decline Cust. 75 Bad Amount Error Fix 77 Invalid AmountDecline Fix 78 Missing Companion Data Error Fix 79 Invalid MerchantError Fix 80 Invalid MOP for division Error Fix 81 Call Low FraudDecline Voice 82 Call Medium Fraud Decline Voice 83 Call High FraudDecline Voice 84 Call Unavailable Fraud Decline Voice 85 DuplicatedOrder # Error Fix 86 Auth Recycle Host down Error Wait 87 InvalidCurrency Error Fix 88 Invalid Purch. Level III Error Fix 89 Credit FloorDecline Cust. 91 Approved Low Fraud Approved None 92 Approved MediumFraud Approved None 93 Approved High Fraud Approved None 94 ApprovedFraud Service Unavailable Approved None 95 Invalid Data Type Error Fix96 Invalid Record Sequence Error Fix 97 Percents Not Total 100 Error Fix98 Issuer Unavailable Decline Resend 99 No Answer/Unable to send ErrorResend A1 Payments Not total Order Error Fix A2 Bad Order Number ErrorFix A3 FPO Locked Error Wait A4 FPO Now Allowed Error Call A5 AuthAmount Wrong Error Fix A6 Illegal Action Error Fix A8 Invalid Start DateError Fix A9 Invalid Issue Number Error Fix B1 Invalid Transaction TypeError Fix B5 Not on file Decline Fix B7 Fraud Decline Cust. B8 Bad DebtDecline Cust. B9 On Negative File Decline Cust. C1 Invalid IssuerDecline Cust. C2 Invalid Response Code Decline Fix C3 Excessive PIN TryDecline Cust. C4 Over Limit Decline Cust. C5 Over Freq Limit DeclineCust. C6 Over Sav Limit Decline Cust. C7 Over Sav Freq Decline Cust. C8Over Credit Limit Decline Cust. C9 Over Credit Freq Decline Cust. D1Invalid For Credit Decline Fix D2 Invalid For Debit Decline Fix D3 RevExceed Withdrawal Decline Cust. D4 One Purchasing Limit Decline Cust. D5On Negative File Decline Cust. D6 Changed Field Decline Fix D7Insufficient Funds Decline Cust. D8 Encrypted Data Bad Decline Fix D9Altered Data Decline Fix E3 Invalid Prefix Decline Fix E4 InvalidInstitution Decline Fix E5 Invalid Cardholder Decline Fix E6 BIN BlockDecline Fix E7 Stored Approved None E8 Invalid Transit Routing NumberError Fix E9 Unknown Transit Routing Number Error Fix F1 Missing NameError Fix F2 Invalid Account Type Error Fix F3 Account Closed ErrorCust. F4 No Account/Unable To Locate Error Fix F5 Account holderDecreased Error Cust. F6 Beneficiary Decreased Error Cust. F7 AccountFrozen Error Cust. F8 Customer Opt Out Error Cust. F9 ACHNon-Participant Error Cust. G1 No Pre-note Error Fix G2 No Address ErrorFix G3 Invalid Account Number Error Fix G4 Authorization Revoked byConsumer Error Cust. G5 Customer Advises Not Authorized Error Cust. G6Invalid CECP Action Code Error Fix G7 Invalid Account Format Error FixG8 Bad Account Number Data Error Fix G9 No Capture Decline N/A H1 NoCredit Function Decline N/A H2 No Debit Function Decline N/A H3 RevExceed Withdrawal Decline Cust. H4 Changed Field Decline N/A H5 TerminalNot Owned Decline N/A H6 Invalid Time Decline Fix H7 Invalid DateDecline Fix H8 Invalid Terminal Number Decline Fix H9 Invalid PINDecline Fix J1 No Manual Key Decline Fix J2 Not Signed In Decline Fix J3Excessive PIN Try Decline Cust. J4 No DDA Decline Fix J5 No SAV DeclineFix J6 Excess DDA Decline Cust. J7 Excess DDA FREQ Decline Cust. J8Excess SAV Decline Cust. J9 Excess SAV FREQ Decline Cust. K1 Excess CardDecline Cust. K2 Excess Card Freq Decline Cust. K3 Reserved FutureDecline N/A K4 Reserved Closing Dec line N/A K5 Dormant Decline Cust. K6NSF Decline Cust. K7 Future RD Six Decline N/A K8 Future RD SevenDecline N/A K9 Transaction Code Conflict Decline Fix L1 In ProgressDecline Wait L2 Process Unavailable Error Resend L3 Invalid ExpirationError Fix L4 Invalid Effective Error Fix L5 Invalid Issuer Decline FixL6 Tran not allowed for cardholder Decline Cust. L7 Unable to DetermineNetwork Error Call Routing L8 System Error Error Call L9 Database ErrorError Call M1 Merchant Override Decline Decline Cust.

Based upon the action identified in the table, authorization responserules system 202 can accept a transaction, decline a transaction,request correction of data, or perform other suitable functions. Forexample, based on information supplied by the merchant using transactiondata format system 108 or other suitable systems, authorization responserules system can generate an authorization response as shown. Forexample, if there are no problems with the transaction data and thetransaction is authorized, then “Code 0” would be returned indicatingthat the transaction was approved. If the card was identified as stolenor otherwise needing to be picked up, then “Code 4” would be generated.Depending on the type of function being performed, the data provided,and the rules of the specific financial processing system beingutilized, either the transaction processing system or the financialprocessing system would implement the rule shown in TABLE 3.Furthermore, a suitable group of two or more rules can be defined asmandatory, such as to prevent unauthorized use of the data, for fraudprotection, for quality control, or for other suitable purposes.

Address verification rules system 204 receives transaction data andgenerates address verification response rules error data. In oneexemplary embodiment, address verification rules system 204 candetermine whether an address is correct, whether fraud indicators exist,or other suitable functions. For example, the exemplary authorizationresponse rules shown in TABLE 4 can be implemented by addressverification rules system 204:

TABLE 4 AVS RULE CODE No address supplied A Bill-to address did not passAuth Host edit checks B AVS not performed C Issuer does not participatein AVS D Edit-error - AVD data is invalid E System unavailable ortime-out F Address information unavailable G Transaction Ineligible forAVS H Zip Match/Zip4 Match/Locate match I Zip Match/Zip 4 Match/Locateno match J Zip Match/Zip 4 no Match/Locate match K Zip Match/Zip 4 noMatch/Locate no match L Zip No Match/Zip 4 Match/Locate match M Zip NoMatch/Zip 4 Match/Locate no match N Zip No Match/Zip 4 No Match/Locatematch O No match at all P Zip Match/Locate match Q Zip Match/Locate nomatch R

Based upon the action identified in the table, address verificationrules system 204 can accept a transaction, decline a transaction,request correction of data, or perform other suitable functions. Forexample, if there were no address supplied, then “Code A” would bereturned indicating that an address is needed. If the bill-to addresswere improper, then “Code B” would be generated. Depending on the typeof function being performed, the data provided, and the rules of thespecific financial processing system being utilized, either thetransaction processing system or the financial processing system wouldimplement the rule shown in TABLE 4. Furthermore, a suitable group oftwo or more rules can be defined as mandatory, such as to preventunauthorized use of the data, for fraud protection, for quality control,or for other suitable purposes.

Card verification value rules system 206 receives transaction data andgenerates card verification rules error data. In one exemplaryembodiment, card verification value rules system 206 can determinewhether a card has been verified or other suitable functions. Forexample, the exemplary authorization response rules shown in TABLE 5 canbe implemented by card verification value rules system 206:

TABLE 5 CVV2 RULE CODE CVV Match A CVV No match B Not processed C Shouldhave been present D Unsupported by issuer E Invalid F Not applicable G

Based upon the action identified in the table, card verification valuerules system 206 can indicate that there has been a card verificationvalue match, that the transaction has not been processed, or can performother suitable functions. For example, if there were a card verificationvalue match such that the transaction can proceed, then “Code A” wouldbe returned indicating that the transaction was approved. If cardverification is not supported by the card issuer, then “Code E” would begenerated. Depending on the type of function being performed, the dataprovided, and the rules of the specific financial processing systembeing utilized, either the transaction processing system or thefinancial processing system would implement the rule shown in TABLE 5.

Processing status rules system 208 receives transaction data andgenerates processing status rules error data. In one exemplaryembodiment, processing status rules system 208 can determine whether atransaction has been authorized, whether fraud indicators exist, whetheran account number or PIN number is invalid, or other suitable functions.For example, the exemplary authorization response rules shown in TABLE 6can be implemented by processing status rules system 208.

TABLE 6 RULE CODE PROCESS SUCCESS A0 UNKNOWN ERROR A1 NETWORK ERROR A2DB ERROR A3 CORRUPT MESSAGE A4 BAD DATA A5 TIMEOUT A6 SET ERROR A61 AUTHRESPONSE FORMAT ERROR A7 AUTH RESPONSE CODE ERROR A8 CAPTURE RESPONSEFORMAT ERROR A9 CAPTURE RESPONSE ERROR A10 BASIC VALIDATION ERROR A11CANT PROCESS SET MESSAGE ERROR A12 MEMORY ERROR A13 AUTH STATE ERROR A14AUTH REV STATE ERROR A15 CAP STATE ERROR A16 CAP REV STATE ERROR A17CRED STATE ERROR A18 CRED REB STATE ERROR A19 SALE REV AMT ERROR A20AUTH REV AMT ERROR A21 MERCH ID MISMATCH A22 FAILED TO START CAPTURE A23NOTHING TO CAPTURE A24 CANT OPEN BATCH A25 BATCH ALREADY OPEN ERR A26BATCH ALREADY CLOSED ERR A27 UNKNOWN EXCEPTION ERROR A28 MEMORYEXCEPTION ERROR A29 SET MESSAGE ALREADY SENT A30 ERROR BAD CREDIT AMOUNTA31 ERROR BAD CREDIT REV AMOUNT A32 ERROR BAD CAPTURE AMOUNT A33 ERRORBAD CAPTURE REV AMOUNT A34 ERROR BAD AUTH AMOUNT A35 ERROR BAD AUTH REVAMOUNT A36 ERROR BATCH NOT OPEN A37 ERROR CANTFINDBATCH A38 BACKENDERROR A39 NOT MOST RECENT AUTH A40 ERROR CANTADDCARDRANGE A41 ERRORCUSTOMERIDNOTFOUND A42 ERROR CUSTOMEREXISTS A43 ERRORCUSTOMERIDNOTSPECIFIED A44 ERROR NO ACQUIRER BIN A45

Based upon the action identified in the table, processing status rulessystem 208 can accept a transaction, decline a transaction, requestcorrection of data, or perform other suitable functions. For example, ifa timeout has occurred, then “Code A6” would be returned indicating thatthe transaction was approved. If the customer ID were not found, then“Code A42” would be generated. Depending on the type of function beingperformed, the data provided, and the rules of the specific financialprocessing system being utilized, either the transaction processingsystem or the financial processing system would implement the rule shownin TABLE 6. Furthermore, a suitable group of two or more rules can bedefined as mandatory, such as to prevent unauthorized use of the data,for fraud protection, for quality control, or for other suitablepurposes.

Downgrade rules system 310 receives transaction data and generatesdowngrade rules error data. In one exemplary embodiment, downgrade rulessystem 310 can determine whether fraud indicators exist, whether anaccount number is missing, or other suitable functions. For example, theexemplary downgrade rules shown in TABLE 7 can be implemented bydowngrade rules system 310.

TABLE 7 CODE RULE A Address verification not requested B Addressverification data does not match issuer data C Invalid merchant categorycode for transaction D Invalid purchase identifier E Transaction notapproved F Not a network card G Transaction identifier is invalid HPrimary account number is missing

Based upon the action identified in the table, downgrade rules system210 can accept a transaction, decline a transaction, request correctionof data, or perform other suitable functions. For example, if theaddress verification data does not match the issuer data, then “Code A”would be generated. If an invalid purchase identifier were provided,then “Code D” would be generated. Depending on the type of functionbeing performed, the data provided, and the rules of the specificfinancial processing system being utilized, either the transactionprocessing system or the financial processing system would implement therule shown in TABLE 7. Furthermore, a suitable group of two or morerules can be defined as mandatory, such as to prevent unauthorized useof the data, for fraud protection, for quality control, or for othersuitable purposes.

In operation, system 200 allows transaction rules to be performed forprocessing of transaction data. System 200 allows a central gateway toperform transaction processing for a plurality of merchants so as toallow each merchant to interface with two or more financial processingsystems, such as by ensuring that the transaction rules of eachfinancial processing system are being implemented. Likewise, system 200allows the payment gateway to implement transaction processing rules, soas to provide fraud detection, processing, or other suitable functions.

FIG. 3 is a diagram of a system 300 for providing processing status rulefunctionality in accordance with an exemplary embodiment of the presentinvention. System 300 includes processing status rules system 208 anddatabase rules system 302, validation rules system 304, network rulessystem 306, and financial processor rules system 308, each of which canbe implemented in hardware, software, or a suitable combination ofhardware and software, which can be one or more software systemsoperating on a general purpose processing platform.

Database rules system 302 receives transaction data and generatesdatabase rules error data. In one exemplary embodiment, database rulessystem 302 can determine whether a database error has occurred, suchthat transaction data processing should be stopped, retried, or whetherother suitable functions should be performed. For example, the exemplarydatabase rules shown in TABLE 8 can be implemented by database rulessystem 302.

TABLE 8 DATABASE RULES CODE Database Open Error C1 Database Update ErrorC2 Database Close Error C3 Database Delete Error C4 Database ExceptionError C5 Database Foreign Key Error C6 Database Wrong Number Records C7Error - Failed to Connect C8 Error - Failed to Connect - SA C9

Based upon the action identified in the table, database rules system 302can indicate database conditions affecting transaction processing orperform other suitable functions. For example, if a database is beingupdated when access is attempted, then “Code C2” would be returned. If aforeign key were submitted to the database, then “Code C6” would begenerated. Depending on the type of function being performed, the dataprovided, and the rules of the specific financial processing systembeing utilized, either the transaction processing system or thefinancial processing system would implement the rule shown in TABLE 8.Furthermore, a suitable group of two or more rules can be defined asmandatory, such as to prevent unauthorized use of the data, for fraudprotection, for quality control, or for other suitable purposes.

Validation rules system 304 receives transaction data and generatesvalidation rules error data. In one exemplary embodiment, validationrules system 304 can determine whether a validation error has occurred,whether fraud indicators exist, or can perform other suitable functions.For example, the exemplary validation rules shown in TABLE 9 can beimplemented by validation rules system 304.

TABLE 9 VALIDATION RULE CODE ERR VALIDATION AGENT ID B0 ERR VALIDATIONAMOUNT B1 ERR VALIDATION AUTHACTION B2 ERR VALIDATION AVSADDRESS B3 ERRVALIDATION AVSZIPCODE B4 ERR VALIDATION BANKID B5 ERR VALIDATION BIN B6ERR VALIDATION CASHBACKAMT B7 ERR VALIDATION CCCLIENTID B8 ERRVALIDATION CHAINID B9 ERR VALIDATION CUSTOMERDISCOUNT B10 ERR VALIDATIONCUSTOMERADDR B11 ERR VALIDATION CUSTOMEREMAIL B12 ERR VALIDATIONCUSTOMERID B13 ERR VALIDATION CUSTOMERNAME B14 ERR VALIDATIONCUSTOMERORDREF B15 ERR VALIDATION CUSTOMERPASSWDHASH B16 ERR VALIDATIONCUSTOMERPHONE B17 ERR VALIDATION CVV2 B18 ERR VALIDATION EXTTRANSREF B19ERR VALIDATION GRATUITYAMT B20 ERR VALIDATION INSTTRANS B21 ERRVALIDATION ISSUENUM B22 ERR VALIDATION LANGUAGE B23 ERR VALIDATIONMERCHANTGROUP B24 ERR VALIDATION MERCHANTID B25 ERR VALIDATIONORDERDESCRIPTION B26 ERR VALIDATION ORDERID B27 ERR VALIDATIONRECORDTYPE B28 ERR VALIDATION RECURRING B29 ERR VALIDATION STOREID B30ERR VALIDATION TAXAMT B31 ERR VALIDATION TAXINCLUDED B32 ERR VALIDATIONTERMINALID B33 ERR VALIDATION TRANSDATE B34 ERR VALIDATION TRANSTIME B35ERR VALIDATION ECOM B36 ERR VALIDATION SORTCODE B37 ERR VALIDATIONACNUMBER B38 ERR VALIDATION PAN LUHN B39 ERR VALIDATION PAN LENGTH B40ERR VALIDATION PAN RANGE B41 ERR VALIDATION EXP DATE FORMAT B42 ERRVALIDATION EXP DATE TOO OLD B43 ERR VALIDATION EXP DATE TOO NEW B44 ERRVALIDATION START DATE FORMAT B45 ERR VALIDATION START DATE TOO NEW B46ERR VALIDATION PAN FORMAT B47 ERR VALIDATION CURRENCY FORMAT B48 ERRVALIDATION CURRENCY UNSUPPORTED B49 ERR VALIDATION CURRENCY BAD EXPONENTB50 ERR VALIDATION MERCHANT UNSUPPORTED B51 ERR VALIDATION BRANDUNSUPPORTED B52 ERR VALIDATION BRAND PAN MISMATCH B53

Based upon the action identified in the table, validation rules system304 can determine whether an error has occurred based on data entry,either by internally checking the transaction data for compliance withfinancial processing system requirements or by submitting thetransaction data to the appropriate financial processing system andsubsequently mapping the response data to an appropriate error field,can accept a transaction, decline a transaction, request correction ofdata or perform other suitable functions. For example, if a customerdiscount number were invalid for an authorization, then “Code B10” wouldbe returned. If the terminal ID is invalid, then “Code B33 would begenerated. Depending on the type of function being performed, the dataprovided, and the rules of the specific financial processing systembeing utilized, either the transaction processing system or thefinancial processing system would implement the rule shown in TABLE 9.Furthermore, a suitable group of two or more rules can be defined asmandatory, such as to prevent unauthorized use of the data, for fraudprotection, for quality control, or for other suitable purposes.

Network rules system 306 receives transaction data and generates networkrules error data. In one exemplary embodiment, network rules system 306can determine whether a network error has occurred, such thattransaction data processing should be stopped, retried, or whether othersuitable functions should be performed. For example, the exemplarynetwork rules shown in TABLE 10 can be implemented by network rulessystem 306.

TABLE 10 NETWORK RULES CODE NW OPEN ERROR D1 NW TIMEOUT ERROR D2 NW READERROR D3 NW WRITE ERROR D4 NW SSL OPEN ERROR D5 NW SSL TIMEOUT ERROR D6NW SSL READ ERROR D7 NW SSL WRITE ERROR D8 ERROR CAPTURE REV UPDATE D9ERROR CAPTURE REV BATCH D10 ERROR CAPTURE GET PERCENTAGES D11 ERRORNOTHING TO CAPTURE REV D12 ERROR NOTHING TO CAPTURE D13 ERROR NOTHING TOAUTH D14 ERROR NOTHING TO AUTH REV D15 ERROR NOTHING TO CREDIT D16 ERRORNOTHING TO CREDIT REV D17 ERROR BATCH OPEN NOT SUPPORTED D18 ERROR BATCHCLOSE NOT SUPPORTED D19 ERROR AUTH STATUS D20 ERROR CAP STATUS D21 ERRORUNREVERSIBLE D22 ERROR BAD REVERSAL AMOUNT D23 ERROR BAD REQUEST AMOUNTD24 ERROR ALREADY CAPTURED D25 ERROR INVALID ACTION D26 ERROR PROCESSINGACTION D27 ERROR MISSING TRANSACTION D28 REFERENCE INDEX ERROR REQUESTNOT ALLOWED D29 ERROR SPLIT AUTH NOT ALLOWED D30 ALREADY MARKED ERRORAUTH CREDIT OUT OF RANGE D31 ERROR REQUEST INVALID D32 UNKNOWN PROTOCOLD33 Message Formatting Errors MANDATORY FIELDS ERROR E0 Converter ErrorsFE NETWORK ERROR E1 FE INTERRUPTED SESSION E2 FE BAD RESONSE E3 FEINCOMPLETE RESPONSE E4 Data Validation Errors EXPIRY DATE ERROR F0 ERRORBADMERCHANT F1 ERROR CANTSETPORT F2 ERROR CANTSETALLOWNONSSL F3 SPAYErrors SPAY TABLE ERROR G0 ADDKEYSET SET ERROR G1 INIT PURCHASE ERROR G2BAD MERCHBRAND ERROR G3 NO PCERT ERROR G4 NO KEYSET ERROR G5 NOT CURRENTKEYSET ERROR G6 MISSING CERT ERROR G7 Transaction Errors NO ROUTE ERRORH0

Based upon the action identified in the table, network rules system 306can determine whether a network-related error has occurred, either byinternally checking the transaction data for compliance withrequirements, by submitting the transaction data to the appropriatefinancial processing system and subsequently mapping the response datato an appropriate error field, or by performing other suitablefunctions. For example, if the authorization credit is out of range,then “Code D31” would be returned. If an invalid expiration date wereprovided, then “Code F0” would be generated. Depending on the type offunction being performed, the data provided, and the rules of thespecific financial processing system being utilized, either thetransaction processing system or the financial processing system wouldimplement the rule shown in TABLE 10. Furthermore, a suitable group oftwo or more rules can be defined as mandatory, such as to preventunauthorized use of the data, for fraud protection, for quality control,or for other suitable purposes.

Financial processor rules system 308 receives transaction data andgenerates financial processor rules error data. In one exemplaryembodiment, financial processor rules system 308 can determine whetherfinancial processor rules have been violated, such that transaction datashould be corrected or whether other suitable functions should beperformed. For example, the exemplary financial processor rules shown inTABLE 11 can be implemented by financial processor rules system 308.

TABLE 11 VENDOR PURCHASING VALIDATION RULES CODE VP VALIDATION ERROR NODATA B54 VP VALIDATION ERROR COMMODITY CODE B55 VP VALIDATION ERROR UNITCOST B56 VP VALIDATION ERROR UNIT OF MEASURE B57 VP VALIDATION ERRORDESCRIPTOR B58 VP VALIDATION ERROR QUANTITY B59 VP VALIDATION ERRORVATRATE B60 VP VALIDATION ERROR CALCULATED LINEITEM B61 VP VALIDATIONERROR NO LINE ITEMS B62 VP VALIDATION ERROR CUSTREF B63 VP VALIDATIONERROR TAXINCLUDED B64 VP VALIDATION ERROR TAX B65 VP VALIDATION ERRORPID B66 VP VALIDATION ERROR CALCULATED TOTAL B67 VP VALIDATION ERRORCALCULATED TAX AMT B68 VP VALIDATION ERROR ITEMTOTAL B69 UNKNOWN ERRORTYPE B70 GATEWAY SYSTEM ERROR CONDITIONS B71

Based upon the action identified in the table, financial processor rulessystem 308 can determine whether a financial processor rules error hasoccurred, either by internally checking the transaction data forcompliance with financial processor rules, by submitting the transactiondata to the appropriate financial processing system and subsequentlymapping the response data to an appropriate error field, or byperforming other suitable functions. For example, if there is avalidation error regarding the unit cost, then “Code B56” would bereturned. If the quantity exceeds predetermined bounds or data types,then “Code B59” would be generated. Depending on the type of functionbeing performed, the data provided, and the rules of the specificfinancial processing system being utilized, either the transactionprocessing system or the financial processing system would implement therule shown in TABLE 11. Furthermore, a suitable group of two or morerules can be defined as mandatory, such as to prevent unauthorized useof the data, for fraud protection, for quality control, or for othersuitable purposes.

In operation, system 300 performs processing status rule processing offinancial transaction data. System 300 is used to enforce processingstatus rules, such as rules relating to validation, specific financialprocessors, or other suitable rules. In this manner, system 300 allows acentralized processor to coordinate financial transaction processing forplurality of financial processing systems and merchants.

FIG. 4 is a flow chart of a method 400 for performing transactionprocessing in accordance with an exemplary embodiment of the presentinvention. Method 400 begins at 402 where transaction data is providedusing a transaction data format. In one exemplary embodiment, thetransaction data format can be provided in the form of one or more webpages of data from a payment gateway system. Likewise, each merchant mayhave transaction data processing systems that provide the transactiondata using the transaction data format specified by the payment gateway.The types of transaction data requested can be selected based on theprocessing rule that is being implemented. Other suitable processes canbe used. The method then proceeds to 404.

At 404 a response is received to the transaction data. In one exemplaryembodiment, the response can be received in real time, in batch mode, inthe form of a document, or in other suitable processes. The method thenproceeds to 406.

At 406 it is determined whether a data format violation has beenidentified. In one exemplary embodiment, a data format violation caninclude providing a data field in excess of the maximum data field size,providing alphanumeric data in a data field that should only receivenumeric data, or other data format violations. If it is determined thata data format violation has not occurred at 406, the method proceeds to412. Otherwise the method proceeds to 408 where the format violation isdisplayed. In one exemplary embodiment, the format violation can bedisplayed by receiving format violation description data, and caninclude the data format error or other suitable data to explain to auser what the error was and how to correct it. The method then proceedsto 410.

At 410, correction data is received. In one exemplary embodiment, thecorrection data can be received by prompting the user to enter only thedefective field, by allowing the user to correct multiple fields thatrelate to the defective field, or in other suitable manners. The methodthen returns to 402.

At 412, it is determined whether a transaction rules violation hasoccurred. In one exemplary embodiment, a transaction rules violation canoccur when the value of the data entered meets the data formatrequirements but is otherwise not permitted. Likewise, other transactionrules violations can occur, such as entry of a first data field typewithout entry of corresponding data fields, entry of dates before orafter permitted date periods, or in other rules violations. If it isdetermined at 412 that a transaction rules violation has not occurredthe method proceeds to 414 where the next transaction is processed. Themethod then returns to 402. Likewise, if it is determined that atransaction rules violation has occurred the method proceeds to 416where the rule violation is displayed. In one exemplary embodiment,notification data can be generated to a user that identifies the ruleviolation, displays the data that has caused the violation, or othersuitable data can be provided. The method then proceeds to 418 wherecorrection data is received. In one exemplary embodiment, the correctiondata can include one or more fields in addition to the defective field,or other suitable corrective data. The method then returns to 402.

In operation, method 400 allows transaction data to be processed by acentralized payment gateway or transaction processor, such that amerchant can accept payment types for two or more different paymentprocessors, and does not need to determine whether the data complieswith data formats and rules specified by the financial transactionprocessors, and also does not need to track the status of thetransaction after it has been accepted. Method 400 allows the dataformat and rules to be verified before the data is transmitted to afinancial processor, so as to minimize the probability that thetransaction will be rejected, to increase the speed at which a merchantgets paid, decrease the number of errors experienced by the merchantthat can cause delay or failure of the payment, and to avoid otherproblems.

FIG. 5 is a flow chart of a method 500 for performing transaction ruleviolation processing in accordance with an exemplary embodiment of thepresent invention. Method 500 begins at 502 where response daLa isreceived after submission of transaction data. The method then proceedsto 504.

At 504 it is determined whether an authorization rule violation hasoccurred. In one exemplary embodiment, an authorization rule violationcan include an invalid merchant number, an invalid value in a message,an invalid authorization amount, an unsupported requested function, orother violations. Likewise, an authorization rule result can be anindication that the transaction has been approved, declined, or thatother suitable procedures should be implemented. If it is determinedthat an authorization rule violation has been received the methodproceeds to 516, otherwise the method proceeds to 506.

At 506 it is determined whether an address rule violation has occurred.In one exemplary embodiment, the address rule violation can includesubmitting a transaction for address verification that is not authorizedor is ineligible for address verification, receiving an indication thata zip code is invalid or does not match the account, or other suitableaddress violations. If an address rule violation has occurred the methodproceeds to 516, otherwise the method proceeds to 508.

At 508 it is determined whether a processing rule violation hasoccurred. In one exemplary embodiment, processing rule violations caninclude state errors, such as requesting cancellation of a charge beforea charge has been submitted, submission of a response after the sameresponse has been submitted, or other processing rule violations. If itis determined that a processing rule violation has occurred the methodproceeds to 516, otherwise the method proceeds to 510.

At 510 it is determined whether a card verification rule violation hasoccurred. In one exemplary embodiment, the card verification rules caninclude an indication that a card not present transaction is not allowedfor the user or card, that the card is unsupported by an issuer, orother suitable card verification data. If it is determined that a cardverification rule violation has occurred the method proceeds to 516,otherwise the method proceeds to 512.

At 512 it is determined whether a downgrade rule violation has occurred.In one exemplary embodiment, a downgrade rule can include aprocessor-specific downgrade rule such as address verification notrequested, invalid purchase identified, or transaction identifier beinginvalid. If it is determined that a downgrade rule violation hasoccurred the method proceeds to 516, otherwise the method proceeds to514 and the next transaction is processed.

At 516 the corrective action is displayed. In one exemplary embodiment,the corrective action can include a narrative describing the field inwhich the error was noted, displaying the error field, displaying atemplate of a correct entry field, and other suitable correctiveactions. The method then proceeds to 518.

At 518 corrected response data is provided. In one exemplary embodiment,a user interface can be generated that provides an entry field forproviding the corrected response with additional data, such as dataidentifying responses permitted under the rule, data formats permitted,or other suitable data. The method then returns to 502.

In operation, method 500 allows transaction data to be confirmed forcompliance with one or more processing rules. Method 500 allows a userto immediately correct any data rule violations, such that processingdelays caused by entry of non-complying data can be eliminated.Likewise, method 500 provides a uniform interface for users that allowsusers to interface with multiple financial processing systems withoutdetailed knowledge of the rules of each financial processing system.Although the processes are shown occurring serially with correctionafter each detected mistake, one of ordinary skill in the art willrecognize that the processes can be performed in parallel, that errorflags can be used such that all errors are corrected at one time, orthat other suitable processes can be used.

Although preferred and exemplary embodiments of a system and apparatusfor credit transaction data transmission have been described in detailherein, those skilled in the art will also recognize that varioussubstitutions and modifications can be made to the systems and methodswithout departing from the scope and spirit of the appended claims.

What is claimed is:
 1. A system for processing transaction data for twoor more financial processing systems comprising: a transaction dataformat system receiving transaction data and generating transaction dataformat error data; and a transaction data rules system receiving thetransaction data and generating transaction rule error data.
 2. Thesystem of claim 1 wherein the transaction data format system furthercomprises an extensible markup language data type definition thatdefines allowable transaction data fields, and the transaction dataformat system determines whether the transaction data complies with thedata type definition.
 3. The system of claim 1 wherein the transactiondata rules system further comprises an authorization response rulessystem receiving the transaction data and generating authorizationresponse rule error data.
 4. The system of claim 1 wherein thetransaction data rules system further comprises an address verificationrules system receiving the transaction data and generating addressverification rule error data.
 5. The system of claim 1 wherein thetransaction data rules system further comprises a card verificationvalue rules system receiving the transaction data and generating cardverification value rule error data.
 6. The system of claim 1 wherein thetransaction data rules system further comprises a processing statusrules system receiving the transaction data and generating processingstatus rule error data.
 7. The system of claim 1 wherein the transactiondata rules system further comprises a downgrade rules system receivingthe transaction data and generating downgrade rule error data.
 8. Thesystem of claim 1 further comprising an error display system receivingthe transaction data format error data or the transaction rule errordata and generating notification data containing the transaction dataformat error data or the transaction rule error data.
 9. The system ofclaim 1 further comprising a corrective action system receivingtransaction data format correction data or transaction rule correctiondata and providing the transaction data format correction data ortransaction rule correction data to the transaction data format systemor the transaction rules system.
 10. A method for processing transactiondata comprising: receiving the transaction data at a payment processingsystem; generating data format error data if the transaction data doesnot comply with a data format; and generating transaction rules errordata if the transaction data does not comply with a transaction rule.11. The method of claim 10 wherein generating the data format error datacomprises displaying format violation data.
 12. The method of claim 10wherein generating the transaction rules error data comprises displayingtransaction rule violation data.
 13. The method of claim 10 furthercomprising transmitting the transaction data to a financial processingsystem if data format error data or transaction rules error data has notbeen transmitted.
 14. The method of claim 10 further comprising:receiving corrected transaction data; and transmitting the correctedtransaction data to financial processing system.
 15. The method of claim10 wherein the data format comprises one or more of the group comprisingthe data formats defined in TABLE
 1. 16. The method of claim 10 whereinthe transaction rule comprises one or more of the group comprising therules defined in TABLES 2 through
 11. 17. A system for processingtransaction data comprising: transaction data format means receivingtransaction data and generating transaction data format error data; andtransaction data rules means receiving the transaction data andgenerating transaction rule error data.
 18. The system of claim 17wherein the transaction data rules means further comprises databaserules means generating database error data.
 19. The system of claim 17wherein the transaction data rules means further comprises validationrules means generating validation error data.
 20. The system of claim 17wherein the transaction data rules means further comprises financialprocessor rules means generating financial processor error data for oneof two or more financial processors.